A data controller is included in the electronics of a peripheral device such as a CD-ROM or a hard drive. In FIG. 1, a peripheral device 100 is coupled to a host adapter board (“HAB”) 110 included in a host 120. Peripheral device 100 includes a data storage medium 130 that is coupled to a servo and read/write channel 140. Servo and read/write channel 140 is coupled to a data controller 150 and a microprocessor 160. Data controller 150 is coupled to buffer memory illustrated as a RAM 170 and a peripheral bus 180. Another memory, shown as SRAM 190, is coupled to microprocessor 160 as local storage.
The general function of data controller 150 is to process commands from a requester or initiator, such as host 120. Host 120 can be a personal computer, workstation, server or other peripheral device. Data controller 150 performs data transfers associated to those commands with the data storage medium 130 of peripheral 100, e.g., magnetic or optical disk. In more detail, data controller 150 processes the commands to configure itself for the associated data transfers. The commands may not request data transfers, but may request status of the peripheral device. Data controller 150 must also process these commands.
Different bus architectures and protocols exist for peripheral bus 180 that provide the commands. Such architecture and protocols are defined by, for example, ATA, ISA, IDE, USB, SCSI and Fibre Channel. For example, a SCSI command known as control descriptor block (“CDB”) includes an operational code consisting of a group code and a command code, a logical unit number, logical block addresses (LBAs) if required, a transfer length value if required and a control byte. The transfer length value specifies the number of blocks (or other data units) that are to be transferred with an associated command. Thus, data controller 150 must be able to at least process one of those command protocols.
Typically, data controller 150 processes the commands using firmware. Use of firmware, however, requires increased storage space associated with the data controller. As a result, the physical requirement and cost of data controller 150 are increased. The firmware also requires microprocessor 160 intervention, which prevents microprocessor 160 from performing other tasks and requires more time to process the data transfer due to the time needed to execute the firmware. For example, a data write to data storage medium 130 may be too large for data controller 150 to process while connected to SCSI bus 180. Microprocessor 160 must be interrupted and used to program data controller 150 to disconnect itself SCSI from bus 180. When data controller 150 is capable of receiving more data, the microprocessor is interrupted again and then programs data controller 150 to reconnect itself to SCSI bus 180. Some data writes may require this disconnect/reconnect sequence numerous times. These disadvantages associated with microprocessor 160 limit the data transfer rate between host 120 and peripheral 100. This limiting of the data transfer rate is contrary to the present industry effort to increase that data transfer rate.
To further illustrate, some data transfers can have a sequence of commands where the LBAs are within a certain range. In this case, microprocessor 160 is interrupted numerous times to process the commands associated with the LBAs. This is a particularly wasteful use of microprocessor 160 resources since the LBAs are located within that range and the data controller does not take advantage of this situation.
Therefore, a need exists for a data controller that can provide a data transfer rate greater than a purely firmware oriented data controller, and at the same time minimize the required memory space. The present invention meets this need.